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Abstract 

We view an evolutionary system as being a software 
product line. The core architecture is the unchanging part of 
the system, and each version of the system may be viewed as 
a product from the product line. Each ’’product ” may be de- 
scribed as the core architecture with some agent-based ad- 
ditions. The result is a multiagent system software product 
line . We describe an approach to such a Software Product 
Line-based approach using the MaCMAS Agent-Oriented 
methodology. The approach scales to enterprise architec- 
tures as a multiagent system is an appropriate means of 
representing a changing enterprise architecture and the in- 
teraction between components in it. 

Keywords: Multiagent Systems Product Lines , Enter- 
prise architecture evolution. 


1 Introduction and Motivation 

When dealing with complex systems, and in particu- 
lar systems exhibiting any form of autonomy or autonomic 
properties, it is unrealistic to assume that the system will be 
static. Complex systems evolve over time, and the architec- 
ture of an evolving system will change even at run time, as 
the system implements self-configuration, self-adaptation, 
and meets the challenges of its environment. 

An evolving system can be viewed as multiple versions 
of the same system. That is, as the system evolves it es- 
sentially represents multiple instances of the same system, 
each with its own variations and specific changes. That is 
to say, an evolving system may be viewed as a product line 
of systems, where the core architecture of the product line 


is fixed (i.e., the substantial part of the system that does not 
change), and each version of the evolving system may be 
viewed as a particular product from the product line. 

Similarly, an enterprise architecture may be viewed as 
the core architecture that is unchanging, and various spe- 
cializations of the architecture (as the enterprise evolves) 
implement various products of the product line. 

If we consider the unchanging part of a software system 
or of an enterprise to be the core architecture, the special- 
ization to various products (versions of the system) can be 
viewed as agent-based additions. The result is that an evolv- 
ing system can be viewed as a Software Product Line of 
multiagent systems (MAS). 

Our approach scales to enterprise architectures and soft- 
ware architecture for two reasons. Firstly, a multi agent sys- 
tem (MAS) is a very appropriate means of representing an 
enterprise and the interactions within it, thanks to the or- 
ganizational metaphor that architects the system mimicking 
the real enterprise organization. Secondly, the gap between 
the enterprise architecture and the software architecture is 
mitigated through the addition of architectural concepts at 
the running platform. That is to say, MAS platforms are 
able to manage architectural evolutions and support archi- 
tectural concepts at the implementation level. 

In this paper, we propose a set of modeling techniques 
based on an agent-oriented methodology called Methodol- 
ogy for Analyzing Complex Multiagent Systems (MaCMAS) 
that is designed to deal with complex unpredictable systems 
[1 1] 1 . Specifically, the approach we use is based on an ex- 
tension of MaCMAS that allows to model MAS Product 
Lines (MAS-PL) [14, 13]. This allows us to manage the 

'See www.tdg-seville.info/members/joaquinp/macmas/ for details and 
case studies using this methodology 



modeling of the evolution of the system in a systematic way. 

To the best of our knowledge, this is the first approach 
that deals with architectural changes of MASs based on 
MAS-PL. 

2 Background and Related Work 

The software product line paradigm (hereafter, SPL) au- 
gurs the potential of developing a core architecture from 
which customized products can be rapidly generated, re- 
ducing time-to-market, costs, etc. [1], while simultaneously 
improving quality, by making greater effort in design, im- 
plementation and test more financially viable, as this effort 
can be amortized over several products. The feasibility of 
building MAS product lines is presented in [13]. In [14], 
we discuss the details of how to build the core architecture. 

In a MAS-PL, we can observe the enterprise architecture 
of the system from two different points of view. This dis- 
tinction stems from the organizational metaphor [9, 10, 18]. 
These two views are the following: 

Acquaintance point of view: shows the organization as 
the set of interaction relationships between the roles 
played by agents in models called role models . It fo- 
cuses on the interactions within the system and also on 
representing how a functionality designated by a sys- 
tem goal is achieved. 

Structural point of view: shows agents as artifacts that 
belong to sub-organizations, groups, teams. In this 
view agents are structured into hierarchical construc- 
tions showing the social structure of the system. It 
shows which agents are playing the roles in the Ac- 
quaintance Organization, and thus, shows how system 
goals are achieved by means of agents interacting to 
fulfill the system goals. 

As shown in [7], the acquaintance organization can be 
modeled orthogonally to its structural organization. This 
allows us to change the system goals that are enabled in the 
system by changing the parts of the acquaintance organiza- 
tion present in the structural organization. This in fact, is 
the basis of MAS-PLs. 

The software process of MAS-PLs is divided in two main 
stages: Domain Engineering and Application Engineering. 
The former is responsible for providing the reusable core as- 
sets that are exploited during application engineering when 
assembling or customizing individual applications [4]. En- 
tering into details, we might say that, generally, both stages 
can be further divided into requirements, analysis, design, 
and implementation (a typical software development lifecy- 
cle). 

domain requirements: This phase describes the require- 
ments of the complete family of products, highlighting 


both the common and variable features across the fam- 
ily. In this phase, commonality analysis is of great im- 
portance for aiding in determining which are the com- 
monalities and variabilities. The models used in this 
phase for specifying features show when a feature is 
optional, mandatory or alternative in the family. The 
models used are called feature models [2, 13]. A fea- 
ture is a characteristic of the system that is observable 
by the end user, which in essence represents the same 
concept than a system goal as shown previously [6]. 

domain analysis: This phase produces architecture- 
independent models, i.e. acquaintance organization 
models, that define the features of the family and the 
domain of application. MAS-PLs use role models 
to represent the interfaces and interactions needed to 
cover certain functionality independently (a feature 
or a set of features) [14]. The most representative 
references in the non-MAS-PL field are [5, 17]. 
Similar approaches have appeared also in the OO 
field, for example [3, 16], but all of these approaches 
use role models with the same purpose, namely, 
representing features of the system in isolation from 
the final enterprise architecture. 

domain design: In this phase, a core architecture of the 
family is produced, and is termed the core structural 
organization of the system. The core architecture is 
formed as a composition of the role models corre- 
sponding to the more stable features in the system [13]. 

application engineering: This phase has the responsibility 
of building concrete products. As our purpose in this 
paper is the runtime evolution of the system, we do not 
illustrate it here. 

3 A NASA case study 

The case study we use is a swarm of pico-spacecrafts 
that are used to prospect the asteroid belt. The enterprise 
architecture of the system changes at run-time depending 
on the environment and the state of the swarm. From all the 
possible evolutions we show only two states of the system: 
in the first one the swarm is orbiting an asteroid in order to 
analyze it; in the second, a solar storm occurs in the envi- 
ronment and the system changes its state to protect itself. 

We will show the role models for both states and an ex- 
ample of composition of both of them since both features of 
the system are not completely orthogonal: to protect from 
a solar storm the spacecraft must take two basic steps: (a) 
orient its solar sails to minimize the area exposed to the so- 
lar storm particles ( trim sails) and (b) power-off all pos- 
sible electronic components. Step (a) minimizes the forces 
from impinging solar-storm particles, which could affect the 
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spacecraft’s orbit. Both steps (a) and (b) minimize potential 
damage from the charged particles in the storm (which can 
degrade sensors, detectors, electronic circuits, and solar en- 
ergy collectors). 

4 Modeling an Evolutionary MASs 

As we have shown, each product in a MAS-PL is defined 
as a set of features. Given that all the products present a 
set of features that remain unchanged, the core architecture 
is defined as the part of all of the products that implement 
these common features! 14]. Thus, a system can evolve by 
changing, or evolving, the set of non-core features. 

A product or a state in our evolutionary system can be 
defined as a set of features. Let F = {/i-./ n } be the set 
of all features of a MAS-PL. Let cF c F be the set of 
core features and ncF — F \ CF be the set of non-core 
features. We define a valid state of the system as the set of 
core features and a set of non-core features, that is to say, 

5 = cF U sF, where sF C ncF is a subset of non-core 
features. 

Given that, the evolution from one state to another 
Si is defined as: 

Si = Si— i U nFi^i-i \ dFi,i - 1 

where nFi^-i c ncF is the set of new features and 
dFi^i- i C ncF is the set of deleted features. 

Finally, A 7 ; ?i _i describes the variation between the prod- 
uct of the state i — 1 and the product of the state i, that is to 

say, nFi^-i \dF ifi - 1 . 

In [13], we show that a feature correlates with a role 
model. Thus, for a system to evolve from one state to an- 
other, we must compose or decompose the role models in 
nF and dF. Specifically, we must compose the role models 
corresponding to the features in nF with the role models 
corresponding to the features that remain unchanged from 
the initial state Si- 1 , that is to say S t \ dFi : i- 1 - Decompo- 
sition is used for role models that must be eliminated. 

In the following subsections, we describe role models, 
and the operations for composition and decomposition. 

5 Models 

MaCMAS is the AOSE methodology that we use for our 
approach. It is specially tailored to model complex acquain- 
tance organizations [15]. We use this methodology since it 
is the only that provides explicit support for MAS-PLs. 

For the purposes of this paper, we only need to know 
a few features of MaCMAS, mainly some of the models it 
uses. Although a process for building these models is also 
needed, we do not address this in this paper, and refer the 
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Figure 2. Self-protection from solar storms 
autonomic property model 


interested reader to the literature on this methodology. From 
the models it provides, we are interested in the following: 

a) Static Acquaintance Organization View: This shows 

the static interaction relationships between roles in the 
system and the knowledge processed by them. In this 
category, we can find models for representing the on- 
tology managed by agents, models for representing 
their dependencies, and role models. For the purposes 
of this paper we only need to detail role models: 

Role Models: show an acquaintance sub-organization 
as a set of roles collaborating by means of several 
multi-Role Interaction (mRI). mRIs are used to 
abstract the acquaintance relationships amongst 
roles in the system. As mRIs allow abstract 
representation of interactions, we can use these 
models at whatever level of abstraction we de- 
sire. 

In Figure 1-B and 2-B, we show the role model 
that represents how the swarm orbits an asteroid 
and the one representing the protection from a 
solar storms. In the figures, interfaces, repre- 
sented as boxes, represent the static features of 
roles showing their goals, the knowledge man- 
aged, and the services provided. mRIs, repre- 
sented as dashed ellipses, represent the interac- 
tions between the roles linked to them, show- 
ing their goal when collaborating, their pattern 
of collaboration, and the knowledge consumed, 
used, and obtained from the collaboration. 

b) Behavior of Acquaintance Organization View: The 

behavioral aspect of an organization shows the se- 
quencing of mRIs in a particular role model. It is 
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Figure 1. Orbiting and measuring an asteroid autonomous property 


represented by two equivalent models: 

Plan of a role: separately represents the plan of each 
role in a role model showing how the mRIs of 
the role sequence. It is represented using UML 
2.0 Protocols tateMachines. It is used to focus on 
a certain role, while ignoring others. 

Plan of a role model: represents the order of mRIs in 
a role model with a centralized description. It is 
represented using UML 2.0 StateMachines. It is 
used to facilitate easy understanding of the whole 
behavior of a sub-organization. 

In Figure 1-A and 2-A, we show the plan of the 
role models of our example. 

We must add a new model to MaCMAS in order to rep- 
resent the evolutions of the system. This model is called the 
evolution plan. 

Evolution Plan: Is represented using a UML state machine 
where each state represents a product, and each tran- 
sition represents the addition or elimination of a set of 
features, that is to say, A. In addition, the conditions in 
the transitions represent the properties that must hold 
in the environment and in the system in order to evolve 
to the new product. 
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B) Role Model 


Figure 3. Measure storms model 


In Figure 4, we show part of the evolution plan of our 
case study. There we represent two products, one rep- 
resenting the swarm when orbiting an asteroid, and an- 
other representing the swarm when orbiting and pro- 
tecting from a solar storm. As can be seen, we add or 
delete the feature corresponding to protect from solar 
storm depending on whether or not the swarm is under 
risk of solar storm, which is measured by the feature 
represented in the role model of Figure 3. 
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Figure 5. Composed Role Model 
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Figure 4. Evolution plan of our case study 

6 Evolving from one product to another 

6.1 Composing role models 

It is important to point out that the composition of role 
models is used to map an acquaintance organization onto 
a set of agents; that is to say, a structural organization. 
This mapping is not always orthogonal between all role 
models — applying two related features to a product may re- 
quire their integration. The composition of role model is the 
process required to perform this integration. In the case of 
having orthogonal features, and thus orthogonal role mod- 
els, we must only assign the prescribed roles to the corre- 
sponding agents. 

We have to take into account that when composing sev- 
eral role models that are not independent, we can find: 
emergent roles and mRls , artifacts that appear in the compo- 
sition yet they do not belong to any of the initial role mod- 
els; composed roles and mRls , the roles and mRIs in the 


resultant models that represent several initial roles or mRls 
as a single element; and, unchanged roles and mRls , those 
that are left unchanged and imported directly from the ini- 
tial role models. 

Once those role models to be used for the core architec- 
ture have been determined, we must complete the core ar- 
chitecture by composing role models. In addition, to obtain 
a certain product we perform the same process. Importing 
an mRl or a role requires only its addition to the composite 
role model. The following shows how to compose roles and 
plans. 

When several roles are merged in a composite role 
model, their elements must be also merged as follows: 

Goal of the role: The new goal of the role is a new goal 
that abstracts all the role goals of the role to be composed. 
This information can be found in requirements hierarchical 
goal diagrams or we can add it as the and (conjunction) of 
the goals to be composed. In addition, the role goal for 
each mRI can be obtained from the goal of the initial roles 
for that mRI. 

Cardinality of the role: It is the same as in the initial 
role for the corresponding mRI. 

Initiator(s) role(s): If mRI composition is not per- 
formed, as in our case, this feature does not change. 

Interface of a role: All elements in the interfaces of 
roles to be merged must be added to the composite inter- 
face. Notice that there may be common services and knowl- 
edge in these interfaces. When this happens, they must be 
included only once in the composite interface, or renamed, 
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depending on the composition of their ontologies. 

Guard of a role/mRI: The new guards are the and (con- 
junction) of the corresponding guards in initial role models 
if roles composed participate in the same mRI. Otherwise, 
guards remain unchanged. 

In our case study, the evolution from the product orbit- 
ing , that also have the feature measure storms, to the prod- 
uct protecting from solar storm requires the addition of the 
feature to protect from a solar storm. This is due to two 
reasons: first, the features orbiting and measure asteroid 
and the measure storms belongs to the core architecture, 
and second, the protection from solar storms can happen 
in whichever moment and we must report the last measures 
of the asteroid before powering-off subsystems. Thus, as 
these role models are not orthogonal, we must perform a 
composition of them. This composition, represented in Fig- 
ure 5, is done following the rule prescribed above. As can 
be observed, we have imported all the mRIs and most roles. 
In addition, we have performed a composition of roles Self- 
ProtecSC and the rest in the role model Orbit and measure 
asteroids. 

The composition of plans consists of setting the order of 
execution of mRIs in the composite model, using the role 
model plan or role plans. We provide several algorithms to 
assist in this task: extraction of a role plan from the role 
model plan and vice versa, and aggregation of several role 
plans; see [12] for further details of these algorithms. 

Thanks to these algorithms, we can keep both plan views 
consistent automatically. Depending on the number of roles 
that have to be merged we can base the composition of the 
plan of the composite role model on the plan of roles or on 
the plan of the role model. Several types of plan composi- 
tion can be used for role plans and for role model plans: 

Sequential: The plan is executed atomically in sequence 
with others. The final state of each state machine is super- 
imposed with the initial state of the state machine that repre- 
sents the plan that must be executed, except the initial plan 
that maintains the initial state unchanged and the final plan 
that maintains the final state unchanged. 

Interleaving: To interleave several plans, we must build 
a new state machine where all mRIs in all plans are taken 
into account. Notice that we must usually preserve the order 
of execution of each plan to be composed. We can use al- 
gorithms to check behavior inheritance to ensure that this 
constraint is preserved, since to ensure this property, the 
composed plan must inherit from all the initial plans [8]. 

The composition of role model plans has to be performed 
following one of the plan composition techniques described 
previously. Later, if we are interested in the plan of one of 
the composed roles, as it is needed to assign the new plan to 
the composed roles; we can extract it using the algorithms 
mentioned previously. 

We can also perform a composition of role plans follow- 


[not ( Orbiter. AmllnsideOrbi1(Orbi- 
ter. relativePosi Orbiter orbitK/l] 



Figure 6. Composed plan 


ing one of the techniques to compose plans described previ- 
ously. Later, if we are interested in the plan of the composite 
role model, for example for testing, we can obtain it using 
the algorithms mentioned previously. 

In Figure 6, we show the composed plan for our case 
study. This plan follows an interleaving composition where 
we include the mRI report measures before starting the pro- 
tection from the solar storm. Notice that when finishing 
the solar storm, the system will evolve to the other product 
deleting the feature solar storm protection. Then, the plan 
of the feature orbiting and measure will start from its initial 
state, thus re-starting the exploration of the asteroid. 

6.2 Decomposition of role models 

The decomposition is simpler than composition. When 
the role model to be eliminated is orthogonal to the rest, we 
only have to delete the corresponding roles from the agents 
that are playing them. In the case that the role model is de- 
pendent with others, we have to delete the elements of role 
models and eliminate all the interactions that refer to them. 
Given that the software architecture where the system run 
should support the role concept and its changes at runtime, 
these changes can be made easily with a lower impact on 
the system. 

However, when dependent, several features may appear 
whose role models are related. In these cases some roles 
may have to be decomposed. These roles are those whose 
mRIs belong to the scope of the role model(s) that have to 
be eliminated. In these cases, the role has to be decomposed 
into several roles, in order to isolate the part of the role we 
want to delete. 

In addition, we have to eliminate the mRI(s) of the role 
model(s) to be eliminated from the role model plan or the 
role plans. This is done starting from the plan of the initial 
dependent role models. Each separate role model usually 
maintains the order of execution of mRIs determined in the 
initial model but executing only a subset of mRIs of the 
initial role models. The behavior of the role model to be 
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deleted can be extracted automatically using the algorithms 
described in [12]. This algorithm allows us to extract the 
plan of remaining role models from the initial ones con- 
straining this to the set of mRIs that remains in the model. 

7 Conclusions and future work 

We have described a novel approach to describing, un- 
derstanding, and analyzing evolving systems. Our approach 
is based on viewing different instances of a system as it 
evolves as different ’’products” in a Software Product Line. 

That Software Product Line is in turn developed with an 
agent-oriented software engineering approach and views the 
system as a Multiagent System Product Line. The use of 
such an approach is particularly appropriate as it allows us 
to scale our view to address enterprise architectures where 
various entities in the enterprise are modeled as software 
agents. 

The main advantage of the approach resides in the fact 
that it allows us to derive a formal model of the system and 
of each state that it may reach. This allows us to clearly 
specify the differences from one state of the architecture 
and any subsequent states of that evolving system. This sig- 
nificantly improves our capabilities to understand, analyze 
and test evolving systems. Additionally, thanks to the use 
of MaCMAS which allows for the description of the same 
feature at different levels of abstraction, we can also spec- 
ify and test the architectural changes at different levels of 
abstraction. 

Finally, such an approach provides support at run time 
for the addition and deletion of roles in the architecture. 
It provides reflection mechanisms that enable understand- 
ing of the features, roles, and agents in an enterprise ar- 
chitecture at different levels of abstraction, providing ca- 
pabilities for ensuring quality of service by means of self- 
organization, self-protection, self-healing and other self-* 
properties identified by the Autonomic Computing initia- 
tive. Furthermore, it decreases the distance between enter- 
prise architectures and software architectures, enabling us 
to model enterprise architectures as software architectures 
and exploit all of the advantages of software architectures 
approaches. 
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